-
-
Notifications
You must be signed in to change notification settings - Fork 229
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Initial work towards a parallel dub building by supporting deferred logging #2717
Conversation
✅ PR OK, no changes in deprecations or warnings Total deprecations: 14 Total warnings: 0 Build statistics: statistics (-before, +after)
-executable size=5331080 bin/dub
-rough build time=69s
+executable size=5367944 bin/dub
+rough build time=66s Full build output
|
850b38a
to
9366773
Compare
This design decision looks odd to me. I can't think of any build system (all of which build independent jobs in parallel) that defer logging until after a job is finished. Typically you'd have the output from different jobs running parallel prefixed with the name of the job and often also colorized differently to make the it easy to follow visually. |
E.g. nix build with nix-output-monitor, which I use almost every day: |
That sounds like it has good tradeoffs too. I'm happy to see that implemented, although I feel I've done my part for the initial work on parallelization. |
This introduces the deferred logging struct, unless enabled it should act identical to how it has in the past.
The idea is we would swap every function that
ProjectGenerator.generate
calls to use theDereferredLogState
by ref instead of the global functions.When parallelized we would turn on the deferment and once all the builds have completed for a given parallel set it would print them so that they will not have cross pollution between the builds.